A quick note: the quote attributed to me isn't actually mine. Having said that, I do agree with the quote, but it's not from my post. :-)

@cessen oops :( sorry about that! At least you know I did read your post, 🤣 😳 I've fixed it now.

There is one thing I was surprised to see not in the roadmap: discussion about the RFC/stabilization processes. Maybe it's just my perception, but it seems like a major theme that came up a few times and was raised by multiple leaders of the project (e.g https://internals.rust-lang.org/t/blog-rust-governance-scaling-empathy/9412, https://boats.gitlab.io/blog/post/rust-2019/). Is the plan to make a separate push independent of the roadmap?

@mark-i-m this is a point @nikomatsakis and I went back and forth with; there's certainly general governance stuff that the core team wants to do this year. We were a bit unsure of the level of granularity we'd want to go into stuff like this, given that we don't know exactly how it will turn out, but maybe it's worth pointing out at a high level. Thanks for calling this out!

Thanks @steveklabnik :) Yeah, I didn't necessarily mean a detailed plan, just a mention that this is something to be investigated this year.

One other thing: are there any plans to do something like an impl Period? Past roadmaps have included timelines for key events (e.g. 2017 impl Period or 2018 edition).

I don't think that was explicitly discussed, but I think that after the big 2018 deadline, people aren't eager for more arbitrary deadlines this year :) at least, that's my rough take. Maybe it's a good idea!

I guess an arbitrary deadline could be helpful for some periodic things like annual planning/roadmapping to help prevent the burden getting delayed or from falling on an individual (like you <3). But I was really thinking more of something like the impl Period: time specifically set aside for a purpose. I have read mixed feelings from different people about whether they thought the impl Period was productive or not, though...

I guess an arbitrary deadline could be helpful for some periodic things like annual planning/roadmapping to help prevent the burden getting delayed or from falling on an individual (like you <3).

Hehe, yeah. That was just life this time though; I was advocating for this to be done by January, and then stuff happened. I think while the push for 2018 was going on, I didn't realize how tired I and everyone else would feel afterward.

But I was really thinking more of something like the impl Period: time specifically set aside for a purpose. I have read mixed feelings from different people about whether they thought the impl Period was productive or not, though...

So, the issue with the impl period (and I did hear this from a lot of people) was that it created pressure to ship RFCs before the cutoff. That's what I meant, more than the actual impl period itself.

@steveklabnik I got some feedback on the community team roadmap that I would like to include later today.

I'm skeptical of ever trying impl-periods again. In particular, I think @steveklabnik is right to say that it created pressure. I think the theme of this year, particularly wrt. "sustainability" suggests that we want to move away from such a development model in which we cram development into one period and proposals into another. Instead, we should have a more balanced, organic, and less forced way of doing things. Also, the impl-period idea might fit our rather serial model today but I think it fits poorly with a the parallel nature of the working group model where they spin up and down and they work at different paces. It also seems to me that impl-periods foster unhealthy and periodical workloads for the language teams and compiler teams respectively.

My sense is that we are not planning an "impl Period"-like push this year.

With respect to text about revamping the RFC process or other such governance changes, I think it's probably a good idea, but couldn't quite figure out where it should fit when I was making changes. Part of the problem is that I don't really view this as such a "top-down effort" any more. I think what we want is individual teams working on their process, and some kind of working group ("governance working group") that is helping to carry lessons between teams and to brainstorm with teams about possible improvements to address their problems. The point here being that a lot of this work is falling on teams, and I do think that many of the individual teams noted their desire to make organizational changes, so in some sense the work is already represented.

That said, it seems like it would add clarify overall to identify that we intend to be actively working on our governance this year across the project. Perhaps @steveklabnik we should add back the Core Team section you originally had, with some text like this?

Core team

A major focus for the core team this year will be reviewing and revising our governance process to better fit our current needs. A number of the teams are already actively changing their structure to better cope with organizational debt, and the core team intends to help with that process where possible. Some possible changes include creating new mechanisms for better inter-team communication, improvements to the RFC process, and creating new teams for areas where we don't currently have coverage.

I like it!

I still plan on filing an RFC for a staged RFC process, personally. I think it'll be really great for us.

This looks great overall! :D I am a little puzzled to see the "Async Ecosystem" section mention Tide but not Tokio though? Shouldn't moving Tokio onto std futures be a major push, since there's so much ecosystem around that already? Whereas, as far as I can tell, Tide isn't really being used yet.

Are there any plans to tackle the remaining proc macros features this year? These (along with the never type, but that could probably be worked around) are the remaining issues blocking Rocket from working on stable. Which, with Rocket planning to go async in their next release, would be fantastic from an Async Ecosystem perspective.

Compile with stable Rust: rwf2/Rocket#19

@nicoburns

Are there any plans to tackle the remaining proc macros features this year?

From what I've seen in "All Hands" notes - not as a part of the official roadmap.
I'm going to work on feature(proc_macro_hygiene) occasionally, so parts of it could be stabilized.

I would much rather have the Roadmap list the overarching goal and motivation of each WG than specify internal details;

This is not how our roadmap process really works, that is, we don't have this as a current requirement of the process. Describing details around how a group's goals apply to their projects is pretty normal. For example:

• The cargo team lists "Xargo, cross, Rustup, and WASM-Pack"
• The compiler team talks about RLS 2.0
• The CLI WG talks about assert_cli, assert_fs, and assert_cmd
• The Wasm WG talks about wasm-pack

The Async Ecosystem WG mentioning tide fits right in with these kinds of things.

This comes out of RFC 1728, which lists both "problem statements" as well as "goals". And it does say that the roadmap should be the problem statements, and then that for each release cycle, the teams would plan out specific goals that refered to a problem statement. In practice though, things didn't play out that way. In our 2018 roadmap, both problems and goals are identified throughout. The guide-level explanation lays out the problems, and then the detailed explanation lays out the goals.

Personally, I believe this happened because an open source project like Rust doesn't work the same way as a company does; trying to model agile too directly doesn't really work in this environment. But I digress. Ultimately, this year's RFC follows in the footsteps of last year's. And regardless, litigating the form of roadmaps generally is not really on-topic for this particular roadmap.

If you'd like to see the Async Ecosystem WG drop Tide as a project, I'd suggest reaching out to the leads as I mentioned before, or attending the WG's open meetings on Thursdays.

That's a good point. I guess the core of my gripe is around the perceived focus of Tide vs the ecosystem writ-large given the name of the team. I feel like the primary focus should be "help expand the ecosystem around async/await" (the second part listed in the RFC), with Tide being a particular way the WG intends to do that. While I personally don't see how focusing on Tide contributes to the ecosystem, I agree with you that the Roadmap mentioning Tide isn't uncharacteristic of past Rust Roadmaps. I'll try to find a way to reach out to the Async Ecosystem WG to discuss directly there.

@jonhoo

I'll try to find a way to reach out to the Async Ecosystem WG...

Here is their Discord channel: https://discordapp.com/channels/442252698964721669/474974025454452766

They have a weekly meeting on Thursdays via that channel, so they may take up your concerns as an item to discuss if you can write them up tonight. (I'm not a member of that WG, though, so I can't speak for them or promise that they'll modify their agenda on your behalf.)

@nikomatsakis

I feel overall pretty comfortable with this. I'd be interested to know if there are specific organizational challenges that you think are not represented in the quotes above.

I suppose if you put it like that, the majority of the issues that boats mentioned are covered somewhat. I feel the money issue is not covered in the roadmap at all, and is something that is top of mind for me; not just the issue of how we can compensate productive contributors, but also how we grow the financial resources that the Rust project can leverage. As far as I understand, two people have left Mozilla Corporation's Rust team with no sign of replacement happening -- does that represent a position that MoCo will scale back their direct contribution definitively?

On the overall RFC, for me it ends up feeling not very coherent and rather fragmented -- this is probably a result of the choice to present everything by team. I feel the RFC would probably read stronger for outside users like myself if it was presented more as (a) problem identified by survey or blog post, (b) proposed solution with (c) SMART goals possibly subdivided by teams. I also feel even with the added section on the core team, the governance theme isn't very well represented.

@djc

On the overall RFC, for me it ends up feeling not very coherent and rather fragmented -- this is probably a result of the choice to present everything by team. I feel the RFC would probably read stronger for outside users like myself if it was presented more as (a) problem identified by survey or blog post, (b) proposed solution with (c) SMART goals possibly subdivided by teams.

This is good feedback, thanks. I too am unsure what I think about the team-based format for the roadmap. In fact, @steveklabnik and I already privately expressed some similar reservations of the format, but we ultimately opted not to try and reorganize everything. Part of the reason for this is time: we are already running later than we'd like to get this RFC posted, and I'd rather not introduce further delay. I definitely think that, when it comes time for next year's roadmap, we should revisit some of these ideas.

That said, once the RFC is merged, we have traditionally made a blog post, which is usually the main "point of entry" for people to read about the roadmap. Our plan was to try and give a more "integrated" presentation there.

I feel the money issue is not covered in the roadmap at all, and is something that is top of mind for me; not just the issue of how we can compensate productive contributors, but also how we grow the financial resources that the Rust project can leverage.

My expectation is that the governance WG (just announced!) -- or a successor, depending on how we scope things -- will tackle some of these topics, but not initially. I think it makes sense to let us figure out the processes that work best for these sorts of discussions first.

two people have left Mozilla Corporation's Rust team with no sign of replacement happening -- does that represent a position that MoCo will scale back their direct contribution definitively?

As the current manager of Mozilla's group, I can speak to that. There has been no change in Mozilla's commitment to Rust. We are working on getting authorization to hire replacements for those who left, but that process takes time.

@rfcbot fcp merge

I think it's time to merge this roadmap, and get started on making it a reality! Thanks to everyone for the discussion and feedback.

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Mark-Simulacrum
• @aidanhs
• @alexcrichton
• @ashleygwilliams
• @aturon
• @carols10cents
• @nikomatsakis
• @nrc
• @steveklabnik
• @wycats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

🔔 This is now entering its final comment period, as per the review above. 🔔

By the way, it appears that the rfcbot has not been updated to account for some core team changes. I've checked a few names off on the comment above, and I'm going to manually add one here that is missing:

• @Manishearth

@nikomatsakis Please send a PR against https://github.com/anp/rfcbot-rs/blob/master/rfcbot.toml updating the roster of the core team. :)

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊
The 2019 Roadmap has been merged!
🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊

As usual, we will be putting out a blog post on the blog, summarizing the roadmap for the community. Expect that early next week.

Rendered version link is broken.

It's merged here: https://github.com/rust-lang/rfcs/blob/master/text/2657-roadmap-2019.md

Updated.